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(54) Resource management 

(57) Resource management for controlling alloca- 
tion of a resource to competing, computer processes is 
achieved through the use of a joining function. A 
resource manager is responsive to identification of a 
thread for a first process requesting allocation of the 
resource, when the resource is already allocated to a 
thread for a second process, to establish a joining func- 
tion to the thread for the second process. The joining 
function is operable to notify the resource manager on 
termination of the thread for the second process. The 
resource manager can therefore be operable in 
response to termination of the thread for the second 
process to allocate the resource to the first process. The 
first and second processes can be call handling proc- 
esses for telecommunications apparatus where the 
resource manager provides allocation of a telephony 
resource, such as a modem or network interface, to the 
competing call handling applications. A telephony inter- 
face and the applications can be implemented in the 
Java^" language. 
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DescriptI n 

BACKGROUND OF THE INVENTION 

[0001 ] This invention relates to resource management s 
in a computing environment where a resource manager 
is required to control allocation of a resource to compet- 
ing computing processes. 

[0002] The invention finds particular, but not exclusive 
application, to telecommunicatioVis apparatus where a io 
plurality of competing processes require access to a 
telephony resource, such as a modem device. 
[0003] Classical solutions to resource management in 
such an environment involve a resource manager 
model where a single entity provides an "acquire 75 
resource" and "release resource" primitives, whereby 
would-be users of this resource ask the entity for access 
to the resource. Access may be granted or refused as: 
appropriate. ..... 

[0004] If access to the resource is granted, the so 
requesting process becomes the owner of the resource 
until such time as it chooses to relinquish it by perform- 
ing a "release resource" operation. During its period of ; 
ownership, the owner of the resourcie has exclusive use 
of it, whereby the aim of the resource management 2S 
scheme is achieved. Many specific examples of this 
type of arrangement are known/ 
[0005] However, this, type of arrangement, although ' 
widely used/ has a major weakness/ If the current 
resource owner (frequently a separate unit of execution so 
such as a thread) falls, and exits, due to software - or 
another error, then the resource may end up in a fiferma- 
nently unavailable state because the current owner has 
failed to perform a "release resource" bperatioin before 
terminating. ' / -* 35 

[0006] Conventional software design either ignores 
this problem or tries to avoid it by having the resource 
requester attempt to clean up (release the resource) 
before exiting. This, however, cannot always be 
achieved in a reliable manner, Indeed, with such an 4o 
arrangement, the resource manager must rely bn all of - - 
the resource requesters behaving in a reliable and ' 
deterministic manner in order tp provide overall reliable 
system operation. 

[0007] . This reliance on the individuar requesting proc- 45 
esses is a significant vveakness in many systems; par-' 
tlcularly where those processes may be provided by ^ 
third party vendors, and the quality of 'the prbcesses 
may not always be guaranteed. * ' 

[0008] , Accordingly, an aim of the present inveritlbn is so 
to provide more reliable resource management. " 

SUMMARY OF THE INVENTION , . ' 

[0009]^ 'particular and preferred'aspedfe of the ihven- 55 
tion are .Vet oirt in.t^ accoriipanying independent and 
dependent cfairhs.' Combinations 61 features *frbm the 
dependent jcl^ims may be combined with'fea^^ 



independent claims as appropriate and not merely as 
explidtly set out in the.claims. ^ 
[001 0] In accordance with one aspect of the inventiori, 
there is provided a resource manager operable to con- 
trol allocation of a resource to .competing computing 
processes, the resource manager being responsiye tp 
identification of a thread for a first process requesting 
allocation of the resource, when the resource is already 
allocated to a thread for a second process, to establish 
a joining function to the thread for tiie second process. 
The joining function is operable to notify the resource 
manager on termination of the thread for the second 
process. The resource manager can thereby be opera- 
ble in response to termination of the thread for the sec- 
ond process to allocate the resource to the first process. 
[001 1] An embodiment of the Invention is able to pro- 
vide reliable resource mariagement through the use of a 
joining function, which enables the resource mianager 
simply to join to the thread. wNch is the current resource 
owner. Such a joining function Is a standard language 
component of,: for example, the Java^" language. 
Accordingly, a resource manager in accordance with an 
embodiment of the Invention, .can be provided with a 
single method "acquireDeviceQ" which may be called by 
any process, or application., wishing to use a resource 
(e.g., a telephony device such as a modem). Standard 
language primitives ensure that only one application 
may execute this method at one time, thereby guaran- 
teeing exclusive access. The would-be owning applica-: 
tion can identify its operating thread to the resource 
manager. By effecting the join on the thread which is the 
current resource owner, the resource manager is ablcf 
simply to wait until the owning application thread termi- 
nates, at which time the join language function notifies 
the resource manager that the previously owriing appli- 
cation has terminated; This notification Is provided by , 
the language constructs irrespective of the manner in 
which the previous owning application, terminated. The 
resource manager is then able to allocate the resource 
to the requesting application, i ; - 
[0012] Accordingly, an embodiment of the invention 
avoids the problem associate<d with a "release resource" 
primitive. An embodiment of the present invention pro- 
vides the advantages of being simple to Implement, and 
more robust than a conventional "release resource" 
approach; It also removes the reliance upon the appli- 
cations replicitly releasing . the resource, whereby 
extremely reliable operation can be achieved without 
making high demarids on the competing processes. 
[0013] In one embodiment of the irrventlon, resource 
manager comprises object-oriented computer software 
operable in an -object oriented environment and the 
processes are software applications operable In the 
object oriented environment. 

[0014] In one embodiment, the software applications 
comprise one or more bean objects registrable with the 
resource manager and the resource manager com- 
prises one or more' objects of the Java language. The 
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resource manager provides an acquire DeviceQ method 
which can be called by an application reqtresting control 
of the resource. Through the uS6 of the join function of 
the Java language, a language event passively releases 
a resource on termination of a thread identified by the 
join function^ " 

[0015] In an embodiment the resource manager con- 
trols access by ia plurality of telecommunications appli- 
cations to a telephoriy device in a telecommunications 
apparatus. The resource manager can also provide a 
dispatch mechanism for controlling disp3.tching of a call 
received by the telephony device to the telecommunica- 
tions applications;' 

[0016] The resource manager can be provided as a 
computer sottv\^are (Droduct on a carrier medium, such 
as a data storage or a data transmission medium. Alter- 
natively, or in addition, at least paW of the management 
mechanism may be embedded, or hardwired.- in a 
device such as an ASIC. * ' " 
[001 7] In accordance with iahother aspect of the inven- 
tion, there is provided a telecommunications apparatus 
including at least one telephony resource for connection 
to a telecommunications network and a resoui'ce man- 
ager as defined above. The telephony resource can be 
an interface to the telecomnniunications network, such 
as a modem, wherieby the resource manager controls 
access via the telephony resource to an external tele^ 
communications network by, for e)^ample. call process- 
ing applications. ; • 
[001 8] The call processing applications, may, for 
example, be selected from a call answering application, 
a voicemail appiicatidn, a facsimile application and a 
data application: 

[0019] In accordance' with a further aspect of the 
invention, there is provided a computer-implemented 
method of managing allocation of a resource to compet- 
ing processes, the method including: 

responding to identification of a thread for a first. ^ 
process requesting allocation of the resource when 40 . 
the resource is already allocated to a thread for a 
second process; to establish a joining function to 
the thread for the secbhd process; - ■ ^ : ^ 

responding to the joining function notifying termina- . 
tion of the thread for the second process to allocate 45 
the resource to the first process. • 

BRIEF DESCRIPTION OF T HE -DRAWINGS ^ 

[0020] Exemplary embodiments of the present inven- • so 
tion will be described hereinafter, by way ofi^example 
only, with reference to the accompanying drawings in 
which like reference signs relate' to like elements and in 
which: 

Figure 1 is a schematic overview of telecommuni- 
cations apparatus for an embodimient of the present 
invention; 
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Figure 2 is a schematic overview of a soft- 
ware/hardware interface in the apparatus of Figure 
1; 

Figure 3 is a schematic representation of the appa- 
ratus of Figure 1 connected to a telecommunica- 
tions network; f . . . 
Figure 4 is a schematic representation of the rela- 
tionship between various elements of an example 
of the apparatus of Figure. 1 ; . 
Rgure 5 is a schematic representation of a registra- 
tion process for applications; 
Figure 6 illustrates various priorities for applica- 
tions; , 

Figure 7 is a schematic overview of the passing of 
control, between a dispatcher and various applica- 
tions; - 

Rgure-8 is a -flow diagram illustrating call process- 
ing by the dispatcher; 

Figure ? illustrates call processing by an applica- 
tion; ^ . . . 
Rgure 10 illustrates an order of processing of a call 

by various applications; 

Rgure, 11. is a flow diagram representing the 
processing of a request from an application for use 
of a resource; ... 

Figure 1 2 illustrates an alternative to part of the flow 
diagram of Figure 1 1; 

Rgure 13 illustrates the acquisition and release ola 
resource by an application; 
Figure 14. is a schematic representation of part of a 
voicenciail application; 

Rgure 1.5 isa schematic representation of an object 
forming a module of an application; and 
Rgure 16 is a schenriatic representation of the 
remote loading of an application. 

r^FRORIPTlON THE PRE FERRED EMBODY 
MENTS , . . . . , ■ ... 



[0021] , Figure i is a schematic overview of teleconfi- 
munications .apparatus ^ for impiemeriting dh erinbbdi- ' 
ment consistent .witti the present invention. 
[0022] As shown in Figure 1. a telecommunications ' 
device^lO cornprises a microprocessor 12 with associ- 
ated read only memory 1 4. (which may be implemented 
as electrically erasable programmable read only mem- 
ory (EEPROM)). ,and random access memory (RAM) 
16. The microprocessor is connected to a communica- 
tions controller 1 8 (in the present example implemented '■ 
as an ASIC) via a RCI. bus 13. In other embodiments 
other bus protocols could' be used. A clock generator 20 
provides clock signals for controlling the. operation of the 
device 10. RJ11 ports 22 and 24 are provided for con- 
nection to telepl:iQne . lines 23 and 25 at a user's 
premises' It, v\iiirb^;.appreciated that RJ11 conhectors ' 
may be repiaced,bY.alternative connectors'as usedby^a- 
localtelecommunications system. ' . ^. ' V 
[0023] Modems 30 and 32 are corinedted to the FiJl 1 
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connectors 22 and 24 lor connecting the communica- 
tions controller 18 to the telephone lines 23 and 25 at 
the user's premises. Although modem devices 30 and 
32 are provided and the example of the device shown in 
Figure 1 is intended for use with analogue telephone s 
lines, it will be appreciated that alternative interfaces 
can be provided for direct connection to digital tele- 
phone lines (for example ISDN). Similarly, suitable con- 
nections for cable, wireless; satellite and other, 
telecommunication services can be provided. id 
[0024] Also connected to the communications control- 
ler 18 is a hub controller 34 which itself is connected to 
l=W45 connectors 36, 38. 40 and 42 for the connection of 
personal computers, or workstations or other computing 
devices, to the telecommuriications device 10. In the is 
present instance four RJ45 connectors are provided, 
although other numbers of RJ45 connectors could be ^ 
provided in other examples of the device 1 0 as shown in 
Figure 1. As well as parallel RJ45 type connectors for 
connections to computer equipment, other digital inter- ; 20 
faces (not. shown) could be provided In the foriii of, by 
way of examples, a serial port, a USB port, a firewire 
connector, etc. Persistent storage in the form of a disc 
drive 50 is connected to the communications controller 
which, in the present instance, also provides the func- 2S 
tions of a disc controller. Alternatively, a separate disc ' 
controller could be provided externally to the communi- 
cations controller 1 8. Other forms of persistent storage, 
for example solid state storage, could be provided in ' 
addition to or instead of the disc drive SO. A key but- 30 
ton/LED interface 52 allows the connection of LED indi- 
cators 56 and key buttons 54 for the display of ' 
information and for the input of information.. Other forms 
of input and/or output devices, such as a keyboard, a^ 
display, a pointing device, etc., could be provided in; 35 
addition to or Instead of the LED iixiicatprs and key but- 
tons.-. 

[0025] . A coder-decoder (CpDEC 58) is prdvided for 
the connection of loudspeakers 50. arid a nriicrophone 
62 for. the output and. input of audio informatidn: An 40 
infra-red unit 64 cap be provided to enable infra-red "' 
control of the device 10 apd/or for infra-red porting of 
information between the device 10 and another device, ■ 
such as for: example a computer. • 
[0026] . Figure 2 is a schernatic overview of the soft- 45 
ware/hardware interface in the device 10. As shown in 
Figure 2. an operating system 72 resides 6n the hard-' 
ware 70 of the telecommunications dievice 10. All serv- 
ices and applications in the particular embodiment of 
the device are based on the Java™ Development Kit 74. so 
A web server 78 provides complete internet web and 
proxy server functions with support for f)lUggable serv- 
lets. The web server 78 and the sery|ets rriay be com- 
patible with Jhe Java progranrinriing eriyironment: It 
includes a- builMn .configurable cache and , enables web ss 
pagecupdates^^tp -be, batch loaded and preloaLded. An 
object-prientecl. database 76 is . pi-ovidilcl' for F)ersistent 
data storage, the database 76 being Held b'h the disc 



drive 50 in the present example of the device 10. 
[0027] A text to speech system (TTS) 82 converts text 
into audible speech,, which can: be played back on the 
speakers 60 or on a telephone connected to the tele- 
communications device 10. A telephony platform 80 
completes the main software platform on which, applica- 
tions reside. . 
[0028] A post office and address pool service. 86 pro- 
vides unified messaging through, the integration of 
voicemail, e-mail, facsimile and paging services, f^es- 
sages can be accessed by phone and persorial compu- 
ter locally, or remotely Users can also access 
messages via any Point of, Presence (POP) e-maii client 
or HyperText Markup Language (HTML) web browser. 
[0029] A voicemail. application 88 provideis voicemail 
and answering machine, services. I^i, functions . as' ah | 
answering machine configurable for voicenrmil. The but- 
tons 54 can be used to provide play and delete func- 
tions, and the answering machine functions are also 
accessible through the telephone and voicemail. Vari- 
ous telephony functions such as smart ring detection, 
caller identity (ID) and automatic announcements based 
on preselected parameters, such as caller ID, ring type, 
time of day. date and so on, can be prox^ded. . 
[0030] An e-mail application 90 provides e-mail func- 
tionality which is acc^ible locally and remotely. A fax 
application 92 provides. fax services, and a paging appli- 
cation 94 provides pagirig services. Other services 96 
may be provided by otfier applications such as, for 
example, an address book function, 
[0031] Accordingly, the telecommunications device 16 
provides a unified interface for incoming and outgoing 
communication. It allows users to conrpose e-mail imes- 
sages, as well as to fonward and receive faxes and 
voicemails as e-mails,. Access to ail of the functionality 
of the device can be achieved by means of a web 
browser via, for example, a HTML, or Java front end. 
[0032] Figure 3 is.a schematic overview representing 
the use of the telecommunications device 10 at a sub- 
scriber location with, connected thereto, .a personal 
computer or workstation 100. First and second tele- 
phone lines 106 and 106 connect the telecommunica- 
tions device to a public switched telephone network 
(PSTN) 110. The connection to tiie PSTN can be by 
analogue or digital connection, either directly or indi: 
rectly, via a cable, wireless, satellite or any other man- 
ner. Optionally, a. telephone 102 and a facsimile (fax) 
machine 104 may also be connected to the lines 106 
and 108. Through the telecommunications device, com- 
munications .may be made .to another such telecommu- 
nications' device 101, , a remote pager 112. a remote 
personal computer or workstation 1 14, a , remote tele- 
phone HS. a remote server station 118, and so on. 
[0033] Figure 4 is a schematic representation of the 
relationship between, various applications, and ele- 
ments of the telephony platform 80, the operating sys- 
tem 72 and the modems, 30. 32 shown in Figures 1 and 
2. ' • •' ^- / 
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[0034] The arrangement shown in Figure 4. enables 
allocation of the modem devices 30 and '32:to the indi- 
vidual applications. - ' ' * ' 
[0035] Each of the modems 30 arid 32 is functionally 
connected to correspondihg device drivers 1 22 and 1 42 s 
respectively, ^which form part of the operating system 
72. Also, respective dispatchers 124 and 144 are pro- , 
vided in the telephony platform 80 for managing the allo- 
cation of the first, and second, modems, respectively, to . 
the various applicatiohs '126. 128. 130 and 146. 148, io 
150, respectively. 

[0036] As shown in Figure' 4, first instances of a voice 
application 1 26. a fax application 1 28 and a data* appli- 
cation 130 are associated with the dispatcher 124. The 
instances 126. 128 and iSO-'of the applications form, is 
functional modules for peflormihg appropriate func- 
tions. Second instanceJs of^ voice application 146. a fax 
application 148 and a data applicatidn tSO are associ- . 
ated with the dispatcher 144.' The f irst and second , 
instances 126 and 146 of ^ voice application may relate so 
to the same voice application, or to different voice appli- 
cations. Similarly.' the first and second instances 128 
and 146 of a fax application may relate to the same fax 
application or to different fax applications. The same ' 
applies to the first and second instances 130. 150 of a -25 
data application. Also.' it should be noted that there.may 
be 0. 1 . or moVe'of each type of application associated 
with the respective dispatcher. Accordingly, there: may. 
for example, be two or more data applications associ- 
ated with either of the dispatchers 124 and 144. Also, so 
there may be other forms of applications associated 
with the dispatchei-s 12* and 144. such as..for example. . 
a billing application. The dispatchers 122 and 142 each 
act as resource managers controlling the allocation of 
the modems 30 and 32. respectively: which, each form 35 
system resources, to the competing application. 
[0037] In a one embcdiment consistent with the . 
present invention, the applications are implemented as 
beans, more particularly JavaBeans"^ components. A- 
bean is a reusable software component which can be,. 40 
manipulated visually in a builder tool (e:g, an. editor or 
graphical user interface biiii Id er (GUI builder)). Beans - 
vary in functionality, but they typically sh^re certain 
common defining features including a set of properties. . . 
a set of methods for performing actions, and support for .45 
events and for introspection. The properties allow beans 
to be manipulated programmatically and support cus- 
tomisation of the bean. The methods implement the 
properties. The support for events enables beans to fire 
events and define the events which can be.fired. The. .50 
support for introspection enables the properties, events - 
and methods of the bean to be inspected from exter- 
nally ' . . - . . ' 

[0038] Each application such as those shown in Fig- 
ure 4 which requires to use a telephony device such as ss 
the modems 30. 32 has to register itiself with the dis- .: 
patcher entities 124. 144 responsible for those teleph- 
ony devices. There is one dispatcher per device as 



shown in Figure 4. 

[0039] Figure 5 represents the registration process for 
registering applications such as a voice application 126, 
a fax application 128 and first and second data applica- 
tions 130.1 and 130.2 with the dispatcher 124. At an 
installation, time. . each application wishing to use a 
telephony device has to register itself as a beans lis- 
tener (in the particular embodiment a JavaBeans-style 
listener) with the device dispatcher. The application 
concerned makes a request 174 to the dispatcher 124 
for registration. The device dispatcher 124 is able to 
query each application to establish a defined set of 
characteristics. These characteristics include a priority 
which is pre-allocated to the application. By virtue of the 
priority.the.dispatcher 124 is able to determine whether 
the appiicatibn is. classed as a , voice, a fax. or a data 
application. As will be described in nnore detail below, 
the priority information is then used by the device dis- 
patcher il24:,to prioritise ^e calling of appHcations to be 
notified of a new incoming call. It can also define a typi- 
cal duration for which the application will require access 
to the modem 30 to carry but a telephony function. 
[0040] . TTie dispatcher '124 then maintains a set of 
links 176 to the; individual applications registered with 
the dispatcher! the links being maintained in a register in 
storage, 178. The information relating to an application 
which can be stored in the storage 178 includes the 
name of the application, ;the link' to the applicatioh. the 
type of the application, a priority allocated to the appli- 
cation, and. a typical time required by the application to 
carry out a. telephony function using the modem 30 (or 
32) \ ' ' r - 

[0041] Figure 6 illustrates the various priorities allo- 
cated to, respectively, voice, facsimile (fax) and data 
applications.! Specifically, a voice application (e.g. 126) . 
will be given a priority PI between A and B, a fax appli- 
cation (e.g. 128) will be given a priority P2 between B 
and C and a.data application (e.g. 130) will be given a 
priority between C and , D. where A > B > G :> o: Each 
application will be allocated its own priority so that, 
where there are multiple applications within a given pri- 
ority range, the individual applications can be given sep- 
arate priorities: In a preferred embodiment • of the 
invention, D is the largest number available within a pri- 
ority range. . A is zero, and B and C are integers equally - 
spaced between the. largest number available arid zero. 
The priorities.are used to determine the order in which ^ 
the various, applications ai-e invoked in the event of an 
incoming call. 

[0042] Figure 7 is a schemiatic overview of the passing 
of control between the dispatcher 124" and various appli- 
cations, such .^s abplicatiohs 126; 128 and 130, The 
dispatcher cycles between two basic states 190 and 
194. Jn .state", l4{)' the dispatcher has allocated the 
modem.device.36 to one of'the applications. In state 
194 the dispatcheir is waiting for an incoming calf to be 
received from the mbdem device 30. or alternatively for 
a request from one of the applications 126, 128 and 130 
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to use the modem 30. 

[0043] Figure 8 illustrates a sequence of events which 
will occur when a call is received at the modem 30. 
[0044] Step 160 in Figure 8 represents state 194 in 
Figure 7 at which the, dispatcher idles awaiting a call s 
event from the modem device 30 or a request for use of 
the modem from one of the applications 126. 128 and 
130. When a call event from the modem device 30 is 
detected, the dispatcher 124 refers to the stored char- 
acteristics pi the applications, including the allocated io 
priority, to determine the applidation having the highest 
priority. It then calls that application at step 166 to 
enquire from the application whether it is interested in 
taking up the call concerned. 

[0045] Figure 9 illustrates the basic steps involved in is 
each application determining whether or not it is inter- 
ested in handling the call. Accordingly, with reference to 
Figure 9, on being notified of an incoming* call, an appli- ■ 
cation establishes at step 180 whether it is able to han- 
dle the call. The test performed at step 180 will depend 20 
on the type of application coricerned. It can' use this 
characteristics of the device which has been allocated 
to it to determine whether it can take up the call. For 
example, if the device concerned which has been alio- ' 
cated is not capable pf voice-mode operation, then a ■ 2s 
voice mail application would most likely decline to han- 
dle the call. However. In the; case of connection to the 
modem, the voicemail application would in principle be * 
at>le to handle the call. . / ^ 

[0046] Accordingly, if the iapplication determines that 30 
it can attempt to handle a call, it answers thei call (if not 
already answered) and then must rapidly determine H 
the call is for it or not. For example, if a voice application 
detects a fax calling tone, then it has deterrtiiried that 
the call ijs not for it. If an application decides that the call 35 
is not for it.^theri it must exit as rapidly as possible iand 
return control (188) tp the dispatcher so thait'the dis- 
patcher can pass the call to another application for han- 
dling without handing up. If. however, the application 
does decide to handle the pall, it then requeists that the 40 
modem be allocated to it at step 182. If the modem Is ' | 
acquired! then the application processes th^e at step 
184. On completion, the application harigs up at step 
186 and returns control at step 188 to the diispatcher 
124. The applications 126. 128, 130; thus form func- 45 
tional modules for handling different; types of calL 
[0047] ^ Returning to Figure 8, step 168 corresponds to 
step 1 80 of Figure 9. Accordingly, if an applicatibh is not 
interested in handling a call, cohtrpl'passes back to the 
dispatcher to step 1 62 and the next appiiqati'on in the list so 
of priorities is chosen^ It however, the applicatibh does 
wish to handle the call, .then the appjicatiori m^kes a' 
request to acquire the device (stejD 182 of Figure 9), 
and. in this case^ it being assumed that no other applica- 
tion..h^s.^contro|/of'' the device, the r^ue^t will be ss 
granted. Jh^^dispatcher th waits at^lep 190 (stee'Fig^ 
ure 7)iqr the application to t^ to ensure 

that ; te^rmination " of ", the applicatiori' is ' captured,' ' an 



emtKxJiment of the invention links the dispatcher to ter- 
mination of the application by means, of a TTiread.joinQ 
operation. The use.of the Thread.joinQ operation will be 
described in more detail below. - v . 

[0048] Through tiie use of the various priorities for the . 
individual applications, the dispatcher is able to guaran- 
tee that, as represented in Figure 1 0, a voice application 
126 will be offered the chance to handle calls before a 
fax application 128, which. in turn will have a chance to 
handle calls before a data application 130. This enables, 
an analog telephony call discrimination mechanism to 
work effectively. In particular, Jn the case of analog 
telephony, using modems, it is inrtpossible to determine 
the type of an incoming call without first answering the 
call and finding out what form the call is.; It is, moreover, 
desirable that a voice application: is operable first as it 
would be disconcerting to a voice caller to be presented 
by data tones instead of a voice service. . 
[0049] Accordingly, through the use of tiie priority 
method employed in an embodiment of the present 
invention, a voice application first of all determines 
whether the incoming call is a . fax or a data call, this 
being determined by, either the receipt of appropriate 
tones siupplied by the caller or by silence. The former is 
indicative of a fax call, and the latter.of a data call. If no 
tones are received but the call is not silent, then it is 
assumed to be a voice call. 1 

[0050] Where fax tones or silence is. received, then the 
dispatcher gives a fax application an opportunity to. 
answer the call. A fax application is able to discrirriinate 
between a fax and a data call, because, a fax call will 
normally only generate the fax.cair tone, whereas as a 
data call will be -silent awaiting data tones from tiie 
receiver. Accordingly, if a fax application determines 
that the incoming call is a fax call, it tiien proceeds to 
handle that call. ^ 

[0051 ] If the incoming call is not a fax call, then control 
passes back to the dispatcher, which then allocates the 
call to a data application for handling the call. 
[0052] As mentioned above, there may be more than 
one voice application, more than one fax application 
and more than one data application. In this case, the 
dispatcher allocates a call in accordance with the indi- 
vidual priorities of the applications concerned. The 
order is determined by controlling the priorities which 
are allocated to individual applications so that the appli- 
cations are then called in the appropriate sequence. 
[0053] In the.above. with reference to Figures 8, 9 and 
10, a description has been given of the processing of a 
call received via the modem device 30. It will bfe appre- 
ciated that the process would be the ;Same. if received 
via the modem 32, with the exception . that the dis- 
patcher 144 would be responsible for dispatching the 
tasks to the corresponding instances of voice, fax and 
data applications 146. 148. 150. ; 
[0054] Figure 11 is a description of the processing of 
a request from an application such. as one of the voice, 
fax and data applications. 126, 128 and 130 to the dis- 
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patcher 124 to use the modem device 30. It will be 
appreciated that a similar process is* lalso irrvotved . 
where one of the applications 146; -148 and 150 makes 
a request to the dispatcher 144 for :use of the modem 
device 32. " ''' ' . -5 

[0055] Accordingly, with reference to Figure ll. an, 
application requests the use of the device at^ step 200. 
At step 202, the dispatcher checks whether the device is ^ 
in use or not. If the device is already in use, (i.e. the dis- . 
patcher is at state 190 illustrated in Figure 7) then the io, 
dispatcher 124 reports this back to the requesting appli- 
cation. Optionally a hint indication may be provided at 
step 204 as to the time the device will remain in use. 
thereby enabling the application to decide at step 206 " 
whether to re-try the'request at a predetermined time in 15 
the future, or to abaridoh the request • 
[0056] In an embodimeint to the invention, the applica- 
tion requests the use of the! device by therdispatcher by 
calling an acquireDeviceO primitive: The acquireDe- 
viceO primitive indicates success or failure to the caller 20 
depending on whether the device is currently free or 
not. In order to be able to return the hint* the acquireDe- 
viceO primitive is arranged to return extra information - 
about how long it believes the device will be occupied , 
for, so that the calling application can use this hint to . 25 
implement an effective retry policy. 
[0057] There are a number of possible ways in which 
the dispatcher can determine how long the device will 
be occupied. 

[0058] In a simple form, this can be provided by heu- 30 
ristics based on an application type. The dispatcher . 
knows the basic type of each telephony application by 
virtue of the priority number which is registered in the 
register storage 178 identified in Figure 5. Accordingly, 
on the basis of the type of application currently owning 35 
the device, the dispatcher is able to guess typical values 
of a call duration. For example, a typical duration of a 
voice application (e.g. voicemail) is less than two min- 
utes. A typical duration of a fax application (transmis- 
sion/reception) is of the order of one to five minutes. A , 40 
typical duration of a data application under a Point-to- 
Point Protocol (PPP) is greater than ten minutes, It 
should be noted that these values are only given as . . 
examples, and in an/ particular implementation, other, 
values may be chosen. However, the dispatcher is 4S 
arranged to record the start time of an application and 
the type of application so that when.the acquireDevice 
primitive is called, the dispatcher can deduce: an esti- 
mated remaining time as the difference between the , 
expected duration and the time elapsed since the start so 
time and can provide an indication of this with the 
acquireDevice response to the calling application. The 
calling application can then use this .in step 206 to , 
decide when to try again to obtain the device. 
[0059] Alternatively, as represented in Figure 12, the ss 
dispatcher may provide an additional step 203 of: inter- 
rogating the current user' application. This. interrogation 
could be by means of a re-entrant call, or could alterna- 



tively be by means of inspecting attributes of the current 
user application is provided with suitable methods for 
giving an indication of any further time it expects to con- 
tinue to require the use of the device allocated to it. It 
would, for example, often be the case that a fax applica- 
tion would be able to give a relatively detailed estimate 
of the rernaining time reqiiired in order to finish the Cur- 
rent job. This could be deduced from a transfer rate and 
a volume of fax data still to'be transmitted, for example. 
[0060] ; It would also.be possible for a combination of 
the heuristic and query approaches described above. 
Accordingly, where a query is made to an application, 
and the application is unable or, does not provide any 
indication.pf the possible remaining time it requires use 
of the device, then the hirij could be based on the heu- 
ristic approach, described above. 
[0061] As a result of prpvidirig hint information, it is 
possible for ari* application either to choose to re-try at a 
later time, determined on the basis of the hint provided. ' 
or even to. abandon an attempt to re-try a request for^ 
use of , the device. 

[0062]. : Re^turning to Figure 1 1 , if the device is currently ~ 
not in use, then the dispatcher will be idling in state 194 
shown in Figure d- Accordingly, in step 208. the dis- 
patcher marks the' requesting application as the cun-ent 
user, and m^kes a "cancelGetEventO" call in step 210 in 
order to unblpcKthe dispatcher in step 212. Control theri 
passes (as represented by loop 1 96 in Figure 7) to state 
190 in Figure 7.. In step 214, the dispatcher detects the 
thread allocated to the user application and then waits 
for that: thread to terminate, by means of a join opera- 
tion, for example a java..lang.'mread.join() operation in a 
Java, language. envirpnrnent: The dispatcher idles in 
step 2 1 6 until Thread.jbiriO completes at which point the 
dispatcher hangs up the call niade by the application (if 
this has not already. been done by the application itsielf). 
A device. GetEventO call is made in. Step 220, whereby 
the dispatcher returns yia edge 192 to th4 state 194 rep- ' 
resented.in Figure 7. ^ 

[0063] As mentioned above, with referende to Figures 
8 and" 11. a preferr^i embodiment of the invention uses 
a Thread.jpinO method .in order to detect the termination 
of a thread. The Thread .joinQ method is a standard fea- 
ture of the Java programming environrhent. Other equiv- 
alent join functions may be prpvideci in other operating 
environrrients. This provides an effective and fully relia- 
ble solution to the. determination of' wH 
nates, and consequently ari effective solution to the 
management of a scared resource. 
[0064]. . Clasisi'cal solutions to resource managefrierit 
where a single /e^itjty provides "acquire resource" and 
"release resource" prirnitives, involve would be users of 
the resource , i asking the entity for access to the 
resource.Jn the situation where access to the resource 
is grarrted. , the ' request beconries the oyvnef -^b^^^^^^^ 
resource until! such tjme as it chooses to relinquish it by 
performing a "rele^e resource' operation. During the 
period of ownership, the owner of the resource has'^ 



7 



13 



EP 0 964 333 A1 



14 



exclusive use of it. This scheme, although widely used, 
has a major disadvantage in that if a current resource 
owner fails and exists due to a software or other error, 
then the resource may end up in a permanently unavail- 
able state because the current owner failed to perform a 5 
"release resource" operation before finishing. The use 
of the join method avoids this problem in . that the 
resource management is provided by the Java lan- 
guage itself: Although specific reference is made to a 
Java language, rt will be appreciate that this technique is w 
not limited to the Java language, and can be providjsd in; 
other language environments. 

[0065] In essence, this resource management tech- ■. 
nique can be summarised as follows, with reference to 
Figure 13. The* resource manager (in the present case is 
the dispatcher 124) provides the method "acquireDe- . 
vice" which may be called by any ajDplication wishing to : 
use the resource in question (in the present case the . ; 
telephony device (i.e. the modem 30). Fundamental 
syr>chronisation primitives are then used to make, sure 20 
that only one caller can execute this method at a time, . 
thereby guaranteeing exclusive access. The would be:* 
owner calls the acquireDevice() primitive and identifies 
itsetf 231 to the resource manager (here the dispatcher 
124). In a Java programming environment it can identify^ 25 
itself as an instance of Java.lang.Thread. It thus uses 
the unit oif execution (i.e. the thread) as the means of 
indicating ownership for the resource. 
[0066] The resource manager (the dispatcher 124): . 
then sinrrply waits for the only application thread 233 to / 30 
finish execution before reclaiming control of the device. 
This is achieved using' language constructs in an 
entirely reliable way by the use of the join method on the 
thread 233 which is currently the owner of the resource. ■ 
If the owning thread 233 exit normally or abnormally for 35 
whatever reason, fundamental language synchronisa- 
tion mechanisms allow the resource manager Jo deter- 
mine that ownership has been relinquished at step 234» . 
enabling control to be passed 235 to the would be . 
owner to proceed as a new owning thread 236. ^AO 
[0067]' ' this arrangement effectively replaces a . ^ 
"release resource** primitive by a language event that . . 
provides a fail safe solution to resource management. 
Such an implication is simple to implement and is more 
robust than the use of a **release resource" primitive. In 45 
particular, it is more robust as telephony applications 
requesting u^e of a telephony resource i (such as a 
modem device 30)'are relatively complex and. poten- 
tially prone to failure. Also, such applications may be 
provided by third party veridors whereby limited control so 
over the quality of those applications is possible. ' 
[0068] Figure 14 is a schematic illustration of-part of 
one instance of a voicerhail application which, could 
form an etxample of a voice application 126. The voice- 
mail application is irriplemented as a directed graph 55 
where e^ch of the nodes in the graph corresponds.to a 
telephotiy cbrnpbnent that performs a low:level function 
of the voideifiair system. Such a low level component 



may be performing the functions of a ring counter, 
detecting a caller ID, performing call filtering, answering 
a telephone calL playing ah ^ audio prompt, reading 
DTMF signalling inforrnatibn, reading out a user's mes- 
sages, changing a voice prompt style, ,etc. Arcs; or links.' 
between the nodes are used to traverse fi-om a given 
node to the next node in the graph depending on the 
resufts of the operation in the given node. 
[0069] The nodes are implemented by modules, pref- 
erably by objects, for performing the operation at that 
node.. 

[0070] For example, in the illustrative example of Fig- 
ure 14, a root node 240 provides access to a ring coun- 
ter module 242. The ring counter module determines 
whether a predetermined number 6i rings are received 
(say 2, 3 or 4). If the result returried by the rtiddijle 242 
is "false** (for example the caller hiihg up after the first 
ring) the false arc is followed to a disconnect module 
244 which performs tfie. operations necessary to dis- 
connect the telephone. call.^ If, hoNwever. the ring counter 
module returned a true value (for exarnple at least two 
rings were received), a "true** arc leads to a caller ID 
module 246 which looks to.identify caller ID ihforrnation 
supplied frorn the public switch telephone network. If the 
, caller ID identifies that the call is local (for example cor- 
responding to the couritry code in which the telecommu- 
nications device 1Q is located) control/passes via the 
local arc to a standard style module 248 which sets up 
a standard style;for voicemail messages. For example, 
if the telecommunications device 10 is being used in 
France, the receipt of a French caller ID would cause a 
French language style to be selieJcted for ahswerphone 
functions. Alternatively, if the caller ID was an interna- 
tional ID outside France, a default arc would be followed 
to a style setter module 250 which could, for example, 
set up an Engljsh language style for the answerphone 
functions. From either of the module 2'48 or the module 
250, a respective arc could be followed to an answer 
module 252 which then answers the telephone call. 
Once the call is accepted (answered) control can pass 
via the following arc, to a play greefting module 254 
which cari play the greeting in the chosen style (French 
or English) to the caller. The process can continue as 
represented at 256 to various rhbre complex voicemail 
functions (not showri). , 

[0071] F;igure 14 also shows a further arc from the 
caller ID. module 246. This arc oould be in response to 
identification of, a call from one of a set of nuriibers (e.g. 
for telesales companies) which causes a specific mes- 
sage to be played or the call to be terminated, as repre- 
sented schernatically by the module **handle unwanted 
cair 258. The caller ID rnodule can maintain, or refer- 
ence, a^ table of stich unwarited oumbers. The caller ID 
module is thus able to provide call, filtering with calls 
from selected numbers being discarded or processed in 
a particular way. .For exanipie. the call can be hung up 
even before ringing .the.user*s telephorie sounder. 
[0072] It shoufo be noted that in Figure 14, a directed 
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graph structure is shown in that controf can pass Irom 
various modules to a common modul^^, and indeed con- 
trol can pass back In a re-entrant mahne? to a previous 
or equivalent module (not shown). 
[0073] In the present example, the modules are imple- 
mented as objects, in particuiar language objects using 
the Java programming language. Such an object is rep- 
resented schematically in Fipure 15. The object or mod- 
ule 260 implements an siction 262 by means of a 
method of that object. The result returned by the 
method is in the form of a string 264 which identifies the 
link or arc to a successor ofiject. Thus, in the example 
shown in Figure 15, if the resujts returned are ABC, 
DEF. or C3HI, these correspbnd io labels respectively for 
an arc labelled ABC. DEF/ or GHI, respectively. If the 
result is other than one of the identified labels, then this 
is interpreted as leading to a defauiVarc labelled as ^uch 
in Figure 15. It ishould.be noted that aU^ letter 
representations of the labels have been used ih Figure 
1 5. this does not indicate that the string should be three 
letters, this being merely used for illustrative purposes. 
[0074] The use of an object based structure of this 
type, enables a very flexible definition of a c^ll handling 
application such as a yoicemail application. As teleph- 
ony services become more complex, individual users 
make more and more wijdeiy differing demands on their 
voicemail systems. Some VeqLiiriB complex voicemail 
systems yyith specific welcoming messages to be sent 
out at specific times, and pther users i-equire specific 
messages to be sent out depending on the identity or 
origin of the caller. Also, the use of multiple mail boxes 
for diHerent members of a family, or of a business, and 
more complex functions cah. bften be demanded by 
users. The use of a structure as described above ena^ 
bles an extremely flexible definition of a voicemail sys- 
tem. . . . 
[0075] The. directed graph object is defined as a seri- 
alised object which is accessible by the operating sys- 
tem class loader (in. the present instance a class loader 
found in the Java environment). Serialisation is a feature 
of. for, example, the Java language! A bean object per- 
sists t!y having its properties, fields, and state informa- 
tion saved and restored to and from storage. The 
mechanism, that makes persistence possible is called 
serialisation. When a bean instance is serialised, it is 
converted into a data stream and written to storage.' Any 
applet, application, or tool that uses' that bean can then 
"reconstitute" it by deserialisation. Seen in another way, 
object serialisation supports the encoding of objects, 
and the objects reachable from them, into ia sti-eam of 
bytes: and it supports the complementary reconstruc- 
tion of the object graph from the stream. By defining the 
graph object as a serialised Object it can be created 
externally or internally to the teledornrnunications 
device and can be stored within the telecomniuhications 
device, and called by the class loader When required. 
[0076] Figure 16 illustrates an exairrple where a plu- 
rality of different telephony controls defining voicemail 



systems 270, 272, 274 are stored at a remote web 
server 1 1 8 and can be displayed to the user of the tele- 
communications device 10 using a conventional web 
browser. Using conventional techniques details and 
5 demonstrations of the individual telephony controls can 
^ be supplied to the user by appropriate user actions. 
[0077] Figure 16 illustrates a situation where the user 
has selected one of the telephony controls having a 
desired voicemail functionality and a copy the serialised 
10 object 276 which is identified by a root node and defines 
the voicemail functionality is download from a remote 
server 1 1 8 via the telecommunications network 1 10 (for 
example in response :to a simple drag and drop opera- 
' tion by the user) and stored on the hard disk drive 50 
15 within the telecommunications device 10. As the run- 
time behaviour of the serialised object formed from a 
directed graph identified by a root node is not fixed by a 
program, and because a class loader, is used, the voice- 
mail application is highly dynamic and may come from 
20 anywhere, in particular, from the web over the telecom- 
munications network 110. This provides extreme flexi- 
bility to meet the varying customer requirements as 
~ described above. - 

[0078] The' flexibility provided facilitates the develop- 
25 ment and operation of call answering functions, within 
the telecommunications . device to . provide remote 
access to messages, e-mails and faxes receiv^ and 
retained by the telecommunications device, . 
[0079] The call handling mechanism and/or the vari- 
30 ous applications: and functional modules may be pro- 
vided in the form of a computer program product, that is 
computer rsoftware, on a carrier rnediurn. The carrier 
medium can be a magnetic or optical storage device, or 
' any other form of storage medium, or an wire, optical, 
35 ' wireless , or satellite telecommunications transmissipn 
- medium, or anyiother suitable carrier medium., Alterna- 
tively, or in addition., at least part of it may be emipedded 
or hardwired in a device such as an ASIC. , ; , . . 
. [0080] It will, be appreciated that althiough particular 
40 embodiments of - the invention have been described, 
many modifications/additipns and/or substitutions may 
be made within the scope of the present invention. 
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1. A resource, manager operable to. control allocation 
of a resourcev to .competing computing process^, 
the resource: manager being responsive to identifi- 
cation of a thread for a first process requesting allo- 
50 cation of the resource, when the resource is already 
allocated to a thread for a second process, to 
establish a joining function to the thread for the sec- 
ond process, the joining function being operable to 
notify the resource manager on, terminati/Dn. of the 
55 • thread for thei second process, .and , the resource 
manager being^operabiein response to terminatipri, 
of the thread for the second process to allocate the 
resource to the first process. 
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2. The resource manager of claim 1, wherein the 
resource manager comprises object oriented com- 
puter software operable in an object oriented envi- 
ronment. 

3. The resource manager of claim 2, wherein the proc- 
esses are software applications operable in the 
object oriented environment. 

4. The resource manager of claim 3, wherein the soft- 
ware applications comprise one or more bean 
objects registrable with the resource manager. 

5. The resource manager of any preceding daim, 
wherein the resource manager comprises one or 
more object of the Java language. 

6. The resource manager of any preceding claim, 
comprising an object for acquiring a device. 

7. The resource manager of any preceding claim, 
where the join function is a join of the type provided 
in a Java language environment, wherein a lan- 
guage event passively releases a resource on ter- 
mination of a thread identified by the join function. 

8. The resource manager of any preceding claim for 
controlling access by a plurality of telecommunica- 
tions applications to a telephony device in a tele- 
communications apparatus. 

9. The resource manager of claim 8, comprising a dis- 
patch mechanism for controlling dispatching a call 
received by the telephony device to the telecommu- 
nications applications. 

10. A resource manager operable to control allocation 
of a resource to competing computing processes, 
the resource manager comprising means respon- 
sive to identification of a thread for a first process 
requesting allocation of the resource, when the 
resource is already allocated to a thread for a sec- 
ond process, to establish a joining function to the 
thread for the second process and means respon- 
sive to the joining function notifying the resource 
manager on termination of the thread for the sec- 
ond process to allocate the resource to the first 
process. 

11. A computer software resource manager on a data 
carrier, the resource manager being configured to 
be operable to control allocation of a resource to 
competing computing processes, the resource 
manager being responsive to identification of a 
thread for a first process requesting allocation of 
the resource, when the resource is already allo- 
cated to a thread for a second process, to establish 
a joining function to the thread for the second proc- 



ess, the joining function being operable to notify the 
resource manager on termination of the thread for 
the second process, and the resource manager 
being operable Jri response to termination of the 
5 thread for the second process to allocate the 

resource to the first proceisis. / 

12. Telecommunications apparatus comprising at least 
one telephony resource for connection to a tele- 
10 communications network and a resource manager 
according to any preceding claim for controlling 
allocation of the telephony resource to competing 
computing processes. 

15 13. The telecommunications apparatus of claim 12, 
wherein the telephony resource is an interface to 
the telecommunications network. 

14. The telecommunications apparatus of claim 12 or 
20 claim 13, wherein the telephony resource Is a 

modem. 

15. The telecommunications apparatus of any one of 
claims 12 to 14, wherein the computing processes 

25 comprise call processing applications. 

16. The telecommunications apparatus of claim 15, 
wherein the call processing applications comprise 
at least one application selected from: 

30 

a call answering application; 
a voicemail application: 
a facsimile application; and 
a data application. 

35 

1 7. A computer-implemented method of managing allo- 
cation of a resource to competing processes, the 
method including: 

40 responding to identification of a thread for a 

first process requesting allocation of the 
resource, when the resource is already allo- 
cated to a thread for a second process, to 
establish a joining function to the thread for the 

45 second process; 

responding to the joining function notifying ter- 
mination of the thread for the second process 
to allocate the resource to the first process. 

so 1 8. The method of claim 1 7, wherein the join function is 
a join function of the type provided in a Java lan- 
guage environment, whereby a language event 
passively release a resource on termination of a 
thread identified by the join function. 

55 

19. The method of claim 17, for controlling access by a 
plurality of telecommunications applications to a 
telephony device in a telecommunications appara- 
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tus. 



20. The method of claim 19,; Wherein^^^^ 

device provides an interface to a tel&ommunica- 
tions networtc ^ 

21. The method of claim 20. wherein the telephony 
device is a modem. 
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